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1. Design Patterns for Sorting 


Command Design Pattern 


Command Design Pattern 


When two objects communicate, often one object is sending a command to 
the other object to perform a particular function. The most common way to 
accomplish this is for the first object (the issuer) to hold a reference to the 
second (the recipient). The issuer executes a specific method on the 
recipient to send the command. 


But what if the issuer is not aware of, or does not care who the recipient is? 
That is, the issuer simply wants to abstractly issue the command? 


The Command design pattern encapsulates the concept of the command 
into an object. The issuer holds a reference to the command object rather 
than to the recipient. The issuer sends the command to the command object 
by executing a specific method on it. The command object is then 
responsible for dispatching the command to a specific recipient to get the 
job done. 


Note the similarities between the Command design pattern and the Strategy 
design pattern. 
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In the above diagram, the invoker holds an abstract command and issues a 
command by calling the abstract execute() method. This command is 
translated into a specific action on a specific receiver by the various 
concrete command objects. It is also possible for a command to be a 
collection of commands, called a macro command. Calling the execute 
method of a macro command will invoke a collection of commands. 


Abstract Factory Design Pattern 

We apply the Abstract Factory Design Pattern to abstract the manufacturing of 
the list structure and hide its implementation. Such abstract construction 
together with the abstract specification of the intrinisc structural behavior of the 
list and the abstract specification of extrinsic operations on the list constitute a 
minimal and complete abstract specification of what is called a list software 
component. It provides a framework for writing an open ended number of 
algorithms on list that are independent from any particular list implementation. 


1. Information Hiding 


Information hiding is a tried-and-true design principle that advocates hiding all 
implementation details of software components from the user in order to 
facilitate code maintenance. It was first formulated by David L. Parnas (in 
1971-1972) as follows. 


e One must provide the intended user with all the information needed to use 
the module correctly and nothing more. 


© translation to OOP: the user should not know anything about how an 
interface or abstract class is implemented. For example, the user 
need not and should not know how IList is implemented in order 
to use it. The user should only program to the abstract specification. 


¢ One must provide the implementor with all the information needed to 
complete the module and nothing more. 


© translation to OOP: the implementor of a class or an interface should 
not know anything about how it will be used. For example, the 
implementor need not and should not know how, when, or where 
IList will be used. The implementor should write the 
implementation code based solely on the abstract specification. 


By adhering to the above, code written by both users and implementors will 
have a high degree of flexibility, extensibility, interoperability and 
interchangeability. 


The list framework that we have developed so far has failed to hide MTList 
and NEList, which are concrete implementations of IList, the abstract 


specification of the list structure. In many of the list algorithms that we have 
developed so far, we need to call on MTList .Singleton or the constructor 
of NELiSt to instantiate concrete [List objects. The following is another 
such examples. 


InsertiInOrder.java 


import listFw.*; 


j** 

* Inserts an Integer into an ordered host list, 
assuming the host list contains 

* only Integer objects. 

oy 

public class InsertInOrder implements IListAlgo { 


public static final InsertInOrder Singleton = 
new InsertInOrder(); 
private InsertInOrder() { 


} 


Fs 
* This is easy, don't you think? 
* @param inp inp[O] is an Integer to be 
inserted in order into host. 
*/ 
public Object emptyCase(MTList host, 
Object... inp) { 
return new NEList(inp[0], host); 
bi 


[** 
* Delegate (to recur)! 
* @param inp inp[0] is an Integer to be 
inserted in order into host. 
ay 
public Object nonEmptyCase(NEList host, 
Object... inp) { 
int n Integer )inp[0]; 
int f Integer )host.getFirst(); 
return n < f ? 
new NEList(inp[0], host): 
new NEList(host.getFirst(), 
(IList )host.getRest().execute(this, inp[0])); 
} 


} 


=f 
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The above algorithm to insert in order an integer into an ordered list of integers 
can only be used for a very specific implementation of IList, namely the one 
that has MTList and NELiSt as concrete subclasses. How can we write list 
algorithms that can be used for ANY implementation of the abstract 
specification of the list structure represented by the abstract class IList? 


We can achieve our goal by 


1. abstracting the behavior of MTList and NELiSt into interfaces with 
pure abstract structural behaviors. 

2. applying the Abstract Factory Design Pattern to hide the concrete 
implementation from the user. 


2. Abstract List Behaviors 


The concrete empty list and non-empty list implemented as MTList and 
NEList are now expressed as interfaces as follow. 


package listFw; 


poe 

* Represents the abstract behavior of the 
immutable list structure. 

* A list intrinsically "knows" how to execute an 
algorithm on itself. 

se 
interface IList { 

Object execute(IListAlgo algo, Object... 


inp); 


Top-level abstract list definition 


package listFw; package listFw; 
fet Lt 

* Represents the * Represents the 
immutable empty list. immutable non-empty 

* The empty list has list. 
no well-defined * An immutable non- 

* structural empty list has a data 
behavior: it has no * object called first, 
first and an isomorphic 

* and no rest. * subcomponent called 

ae A rest. Its structural 
interface IMTList * behavior provides 


access to its internal 


extends IList { * data (first) and 
} substructure (rest). 
ui 
interface INEList 
extends IList { 
| es 
* "Gettor" method 
for the list's first. 
* @return this 
INElist's first element. 
wd 
Object getFirst(); 


f** 
* "Gettor" method 
for the list's rest. 
* @return this 
INElist's rest. 
ae 4 
IList getRest(); 


Abstract empty and non-empty list definitions 


3. Abstract List Factory 


Before we describe in general what the Abstract Factory Pattern is, let's 
examine what we have to do in the case of IList. 


e Define an abstract factory interface, [ListFactory, to manufacture 
empty and non-empty IList objects. Put IList, IMTList, 
INEList, IListVistor, and IListFactory in the same package. 
IListFactory is specified as followed. 


IListFactory.java 


package listFw; 


[*=* 
* Abstract factory to manufacture IMTList and 
INEList. 
of 
interface IListFactory { 
yeas 
* Creates an empty list. 
* @return an IMTList object. 
a 
IMTList makeEmptyList(); 


[r* 
* Creates a non-empty list containing a 
given first and a given rest. 
* @param first a data object. 
* @param rest != null, the rest of the non- 
empty list to be manufactured. 
* @return an INEList object containing first 
and rest 
* @exception IllegalArgumentException if 
rest is null. 
wa 
INEList makeNEList(Object first, IList rest); 


IList, IL1stAlgo, and IListFactory prescribe a minimal and 
complete abstract specification of what we call a list software component. We 
claim without proof that we can do everything we ever want to do with the list 
structure using this specification. 


e All algorithms (i.e. visitors) that call for the creation of concrete [List 
objects will need to have an abstract factory as a parameter and use it to 
manufacture [List objects. We usually pass the factory as an argument 
to the constructor of the visitor. The visitor is thus not a singleton. 


InsertiInOrderwithFactory.java 


import listFw.*; 


j** 

* Inserts an Integer into an ordered host list, 
assuming the host list contains 

* only Integer objects. Has no knowledge of how 
IList is implemented. Must 

* make use of a list factory (IListFactory) to 
create IList objects instead of 

* calling the constructors of concrete 
subclasses directly. 

*/ 
public class InsertInOrderwithFactory implements 
IListAlgo { 


private IListFactory _listFact; 


public InsertInOrderwithFactory(IListFactory 
1f) { 


} 


_listFact = lf; 


jf 
* Simply makes a new non-empty list with the 
given inp parameter as first. 
* @param host an empty IList. 
* @param inp inp[O] is an Integer to be 
inserted in order into host. 
*/ 
public Object emptyCase(IMTList host, 
Object... inp) { 
return _listFact.makeNEList(inp[0], 
host); 


} 


, Mitel 
* Recur! 
* @param host a non-empty IList. 
* @param inp inp[O] is an Integer to be 
inserted in order into host. 
ry 
public Object nonEmptyCase(INEList host, 
Object... inp) { 
int n (Integer )inp[0]; 
int f (Integer )host.getFirst(); 
return n < f ? 
_listFact.makeNEList(inp[0], 


host): 
_listFact.makeNEList(host.getFirst(), 
(IList )host.getRest().execute(this, inp[0])); 


} 


The above algorithm only "talks" to the list structure it operates on at the 
highest level of abstraction specified by IList and IListFactory. It does 
know and does not care how IList and IListFactory are implemented. 
Yet it can be proved to be correct. This algorithm can be plugged into any 


system that subscribes to the abstract specification prescribed by IList, 
IListAlgo, and IListFactory. 


e Provide a concrete implementation of the abstract factory that contains all 
concrete subclasses of ILiSt as private static classes and thus hide them 
from all external code. 


CompositeListFactory.java 


package listFW.factory, 
import listFw.*; 


’ ae 

* Manufactures concrete IMTList and INEList 
objects. Has only one 

* instance referenced by 
CompositeListFactory.Singleton. 

* MTList and NEList are static nested classes and 
hidden from all external 

* client code. The implementations for MTList 
and NEList are the same as 

* before but completely invisible to the outside 
of this factory. 

a 
public class CompositeListFactory implements 
IListFactory { 


j=? 


* Note the use of private static. 
ey 
private static class MTList implements IMTList 


{ 

public final static MTList Singleton = new 
MTList (); 

private MTList() { 

is 


final public Object execute(IListAlgo 
algo, Object... inp) { 
return algo.emptyCase(this, inp); 
a 


public String toString() { 
return "()"; 
} 


1 es 
* Note the use of private static. 
“yd 
private static class NEList implements INEList 


private Object _first; 
private IList _rest; 


public NEList(Object dat, IList rest) { 
_first = dat; 
_rest = rest; 


} 


final public Object getFirst() { 
return _first; 
t 


final public IList getRest() { 
return _rest; 
} 


final public Object execute(IListAlgo 
algo, Object... inp) { 
return algo.nonEmptyCase(this, inp); 
} 


public String toString() { 
return 
(String)ToStringAlgo.Singleton.nonEmptyCase(this); 
J 


} 


fue 
* Singleton Pattern 
ny 
public static final CompositeListFactory 
Singleton = new CompositeListFactory(); 
private CompositeListFactory() { 


} 


pn 
* Creates an empty list. 
* @return an IMTList object. 
ei 
public IMTList makeEmptyList() { 
return MTList.Singleton; 
} 


je 
* Creates a non-empty list containing a given 
first and a given rest. 
* @param first a data object. 


* @param rest != null, the rest of the non- 
empty list to be manufactured. 
* @return an INEList object containing first 
and rest 
ay 
public INEList makeNEList(Object first, IList 
rest) { 


} 


return new NEList(first, rest); 


Concrete factory for instnatiating composite lists 


e Pass such a concrete factory to all client code that need to make use of the 
abstract factory to manufacture concrete IList instances. 


Below is an example of a unit test for the InSsertInOrderwithFactory 
algorithm. 


Test_InsertInOrderwithFactory.java 


package listFW.visitor.test; 
import listFw.*; 

import listFwW.factory.*; 
import listFW.visitor.*; 


import junit.framework.TestCase; 


Y ss 
* A JUnit test case class. 


* Every method starting with the word "test" 
will be called when running 

* the test with JUnit. 

ar A 
public class Test_InsertInOrderwithFactory 
extends TestCase { 


public void test_ordered_insert() { 
IListFactory fac = 
CompositeListFactory.Singleton; 
IListAlgo algo = new 
InsertInOrderwithFactory(fac); 


IList listO = fac.makeEmptyList(); 
assertEquals("Empty list", "()", 
list0.toString()); 


IList listi = (IList) list0.execute(algo, 
95); 

assertEquals("55->()", "(55)", 
listi.toString()); 


IList list2 = (IList) list1i.execute(algo, 
30); 

assertEquals("30->(55)", "(30, 55)", 
list2.toString()); 


IList list3 = (IList) list2.execute(algo, 
100); 

assertEquals("100 -> (30, 55)", "(30, 55, 
100)", list3.toString()); 


IList list4 = (IList) list3.execute(algo, 
45); 

assertEquals("45->(30, 55, 100)", "(30, 45, 
55, 100)", list4.toString()); 


IList list5 = (IList) list4.execute(algo, 


60); 
assertEquals("60 -> (30, 45, 55, 100)", "(30, 
45, 55, 60, 100)", list5.toString()); 
J 
i 


The above design process is an example of what is called the Abstract Factory 
Design Pattern. The intent of this pattern is to provide an abstract 
specification for manufacturing a family of related objects (for examples, the 
empty and non-empty IList) without specifying their actual concrete classes 
thus hiding all details of implementation from the user. 


Our example of the list structure framework successfully delineates 
specification from implementation and faithfully adheres to the principle of 
information hiding. 


e IList, IMTList, INEList, IListAlgo, and IListFactory 
provide a minimal and complete abstract specification. 

e InsertInOrderwWithFactory is a concrete implementation of 
IListAlgo that performs a concrete operation on the host list. Yet this 
algorithm need only communicate with the list structure and the list 
factory via their public interface. It will work with any implementation of 
PELSt and Llastractony. 

e CompositeListFactory is a concrete implementation of 
IListFactory. It uses the composite pattern and the visitor pattern to 
implement IList. It only communicates with IListAlgo at and 
knows nothing about any of its concrete implementation. The private 
static attributes provide the proper mechanism to hide all implementation 
details from all code external to the class. 


Click here to access the complete javadoc documentation and UML class 
diagram of the list component described in the above. 


Click here to download the complete source code and documentation of the list 
component described in the above. 


4. Frameworks 


The following is a direct quote from the Design Patterns book by Gamma, 
Helm, Johnson, and Vlissides (the Gang of Four - GoF). 


"Frameworks thus emphasizes design reuse over code resuse...Reuse on this 
level leads to an inversion of control between the application and the software 
on which it's based. When you use a toolkit (or a conventional subroutine 
library software for that matter), you write the main body of the application 
and call the code you want to reuse. When you use a framework, you reuse the 
main body and write the code it calls...." 


The linear recursive structure (ILiSt) coupled with the visitors as shown in 
the above is one of the simplest, non-trivial, and practical examples of 
frameworks. It has the characteristic of "inversion of control" described in the 
quote. It illustrates the so-called Hollywood Programming Principle: Don't call 
me, I will call you. Imagine the [List union sitting in a library. 


The above list framework dictates the design of all algorithms operating on the 
list structure: 


e All algorithms must be some concrete implementation of IListAlgo. 


o Algorithms that require the construction of empty and/or non-empty 
lists, must do so via some abstract list factory, IListFactory. 


e In order to apply an algorithm to a list, one must ask a list to "execute" that 
algorithm, giving it the required input parameter. 


When we write an algorithm on an IL1St in conformance with its visitor 
interface, we are writing code for the IList to call and not the other way 
around. By adhering to the IList framework's protocol, all algorithms on the 
IList can be developed much more quickly. And because they all have 
similar structures, they are much easier to "maintain". The IL1st framework 
puts polymorphism to use in a very effective (and elegant!) way to reduce flow 
control and code complexity. 


We do not know anything about how the above list framework is implemented, 
yet we have been able to write quite a few algorithms and test them for 


correctness. In order to obtain concrete lists and test an algorithm, we call on a 
concrete IListFactory, called CompositeListFactory, to 
manufacture empty and non-empty lists. We do not know how this factory 
creates those list objects, but we trust that it does the right thing and produces 
the appropriate list objects for us to use. And so far, it seems like it's doing its 
job, giving us all the lists we need. 


5. Bootstrapping Along 
Let's take a look back at what we've done with a list so far: 


1. Created an invariant list interface with two variant concrete subclasses 
(Composite pattern) where any algorithms on the list where implemented 
as methods of the interface and subclasses (Interpreter pattern) 

2. Extracted the variant algorithms as visitors leaving behind an invariant 
"execute" method. Accessor methods for first and rest installed. The entire 
list structure now becomes invariant. 

3. Abstracted the creation of a list into an invariant factory interface with 
variant concrete subclass factories. 

4. Separated the list framework into an invariant hierarchy of interfaces and a 
variant implementation which was hidden inside of a variant factory class. 


Is there something systematic going on here? 


Notice that at every stage in our development of our current list framework, we 
have applied the same abstraction principles to the then current system to 
advance it to the next stage. Specifically, we have identified and separated the 
variant and invariant pieces of the system and defined abstract representations 
whenever needed. 


This really tells us about some general characteristics of software development: 


e Software development is an iterative process. You never get the right 
answer the first time and you have to slowly "evolve" your code closer and 
closer to what you want. 

e Every time you change your code you learn something more and/or new 
about your system and/or problem. This is because every new formulation 


of your solution represents a new way, a new view as it were, on the 
problem and this new view highlights aspects you hadn't considered 
before. 

e The revision process is driven along by a repetitive application of the 
abstract decomposition techniques such as separating the variant and 
invariant. 


Are we done with our list refinements? Will we ever be "done"? What do the 
above characteristics say about the way we should approach software 
development? 


Also, now that we have managed to abstract structure, behavior and 
construction, is there anything left to abstract? Or is there one more piece to our 
abstraction puzzle (at least)? 


Abstract Factory Design Pattern 

Explains the Factory Design Pattern, a pattern in object-oriented 
programming whereby a factory is responsible for creating instances of a 
given class of objects. 


One of the nice things about abstraction is that it lets you take care of the 
bigger picture and worry about the details later. Wouldn't it be great if we 
could do that when creating objects? It sure would be handy to be able to 
rely upon some other class to fill in the details for you. With the help of the 
Abstract Factory Pattern, we can. 


The great advantage of this is that we don't have to worry about what kind 
of car we're building. Let's say that you are making various types of car, and 
each car has different types of components you need to worry about. For 
example, say that you have the ability to build a Cadillac Dreadnaught, a 
Citroén BX-TRD, and a Fiat Avanti. Each type of vehicle has the same 
overall structure that all cars share in common: i.e. an engine, wheels, 
steering, brakes, etc. For the sake of simplicity, let's say that a car consists 
of three components: Engine, Chassis, and Steering. Naturally, you can't 
have the same types of Engine, Chassis or Steering in each car, because 
then the cars would all be the same. It won't do to mix-and-match 
components, either. You need all Cadillac parts to go with the Cadillac, and 
all Citroén parts to go with the Citroén, etc. The different parts of the cars 
don't need to do the same thing, either: they need merely conform to an 
interface. Let's encapsulate the decision making process for assigning the 
parts when you build a car. 


Should the main car building program care what kind of car is being built? 
No, it shouldn't. It should just expect the car to behave as all cars should, 
and not care about the specifics. All of the knowledge about the specific 
cars we're building is not contained in the main class of the program, but 
can be updated and changed easily, since the information is only in one 
place. This gives us great flexibility, since we are not limited in our choices 
at all, and can make many different types of car. Let's say that we have a 
simulated car-building plant. It can produce one type of car at a time, but 
can produce any type of car, so long as the workers have the proper 
directions. Each set of plans will dictate how each component of a 


particular car is built. So, in order to change the type of car we're producing, 
we only need to switch the directions. All of the factory workers will follow 
the new directions, producing a new car, based upon the directions. 


That's nice, you say, but won't it get confusing with all kinds of different 
directions running around? Which set do we follow? The solution is pretty 
simple. We have one main set of directions which everyone refers to, and 
we can change what that set of directions looks like. We expect each set of 
directions to provide certain information about how to build a car. It should 
comply to an abstract set of directions that we have in mind. Each real set 
of directions should have the same structure as the abstract directions. Let's 
call the sets of directions Factories. A Factory will build a certain type of 
car, depending upon the type of factory. The specification for what 
directions should contain would be called an Abstract Factory. 


The Client here only knows about the 


AbstractFactory 


and 


AbstractProduct 


s, shielding it from needing to know about the actual behavior of the 


ConcreteFactory 


s and actual 


Product 


A good analogy for this is a pasta maker. A pasta maker will produce 
different types of pasta, depending what kind of disk is loaded into the 
machine. All disks should have certain properties in common, so that they 
will work with the pasta maker. This specification for the disks is the 
Abstract Factory, and each specific disk is a Factory. You will never see an 
Abstract Factory, because one can never exist, but all Factories (pasta 
maker disks) inherit their properties from the abstract Factory. In this way, 
all disks will work in the pasta maker, since they all comply with the same 
specifications. The pasta maker doesn't care what the disk is doing, nor 
should it. You turn the handle on the pasta maker, and the disk makes a 
specific shape of pasta come out. Each individual disk contains the 
information of how to create the pasta, and the pasta maker does not. 


Composite Design Pattern 


Description 


The Composite Design Pattern allows a client object to treat both single 
components and collections of components identically. It accomplishes 
this by creating an abstraction that unifies both the single components and 
composed collections as abstract equivalents. Mathematically, we say that 
the single components and composed collections are homomorphically 
equivalent (from the Latin: homo — same and morph — form ==> to have the 
same form). 


This equivalence of single and composite components is what we call a 
recursive data structure. In recursive data structures, objects are linked to 
other objects to create a total object structure made of many “nodes” 
(objects). Since every node is abstractly equivalent, the entire, possibly 
infinitely large and complex data structure can be succinctly described in 
terms of just three distinct things: the single components, the composite 
components and their abstract representation. This massive reduction in 
complexity is one of the cornerstones of computer science. 


"The Composite Design Pattern is an object-oriented representation of a 
recursive data structure. " 


UML Diagram and Example 


In the UML class diagram below, the Client uses an abstract component, 
AComponent, for some abstract task, oOeration(). Atrun-time, the 
Client may hold a reference to a concrete component such as Leaf 11 or 
Leaf2. When the operation task is requested by the Client, the specific 
concrete behavior with the particular concrete component referenced will be 
performed. 

UML Diagram of Composite Design Pattern Example 


— AComponent : component 


f\ 


+ void : operation() 


+ void : operation() 
+ AComponent : removeChild{AComponent child) 
+ void : addChild{AComponent child) 


+ void : operation() 


- 
-- 
- 


for all c in children: 
c.operation(); 


An example of a composite design pattern implementation with 2 
single, concrete components and one composite, collection component. 


The Composite class is a concrete component like Leaf1 and Leaf 2, 
but has no operation( ) behavior of its own. Instead, Composite is 
composed with a collection of other abstract components, which may be of 
any other concrete component type including the composite itself. The 
unifying fact is that they are all abstractly AComponents. When the 
operation( ) method of a Composite object is called, it simply 
dispatches the request sequentially to all of its "children" components and 
perhaps, also does some additional computations itself. For instance, a 
Composite object could hold references to both a Leaf anda 

Leaf2 instance. Ifa client holds a reference to that Composite object 
and calls its operation( ) method, the Composite object will first 
call operation on its Leaf instance and then operation( ) onits 
Leaf2 instance. Thus composite behavior of Leafi plus Leaf2 


behaviors is achieved without either duplicating code or by having the 
Client object knowing that the two leaf components were involved. 


Composite patterns are often used to represent recursive data structures. 
The recursive nature of the Composite structure naturally gives way to 
recursive code to process that structure. 


Note:The collection of 
AComponent 

s held by 
Composite 


, "children", is shown above as an array. However, the behavior of a 
Composite pattern is independent of exactly how the collection of 


AComponents 


is implemented. If access speed is not an issue, a vector or a list may be a 
better implementation choice. The 


addChild() 
and 


removeChild( ) 


methods are optional. 


In Design Patterns, the abstract component AComponent is shown as 
having accessor methods for child AComponents. They are not shown 
here because it is debatable as to whether one wants the Client to 
fundamentally view the AComponent as a single component or as a 


collection of components. Design Patterns models all AComponents as 
collections while the above design models them all as single components. 
The exact nature of those accessor methods is also debatable. 


List Structure and the Composite Design Pattern 


Going Shopping 


Before I go to the groceries store, I make a list of what I want to buy. Note 
how I build my shopping list: I start with a blank sheet of paper then I add 
one item at a time. 


When I get to the store, I start buying things by going down my list. For 
each item I buy, I mark it off the list. 


After I am done shopping, I go to the cashier and check out my items. 


The cashier scans my items one item at a time. Each time, the cash register 
prints one line showing the item just scanned together with its price. Again, 
note how the cash register builds the list: it start with a blank sheet of paper 
and then add one item at a time. After all items have been scanned, the 
cashier press a key and "poof", the cash register prints a subtotal, then a tax 
amount for all the taxable items, then a total amount, and finally a total 
number of items bought. 


At different store, the cash register not only prints out all of the above, but 
also a total amount of "savings" due to the fact that I have a "member-plus" 
card. Some other stores don't care to print the total number of items bought 
at all. Whatever the store, wherever I go, I see "lists" and "list processing" 
all over. 


The check out cash register uses a program to enter the items and print the 
receipt. At the heart of the program is a container structure to hold data 
(data structure) and a few algorithms to manipulate the structure and the 
data it holds. The simplest way to organize data is to structure them ina 
linear fashion; that is, intuitively, if we can get hold of one data element, 
then there is exactly one way to get to the next element, if any. We call this 
linear organization of data the list structure. In order to write program to 
process lists, it is necessary to define what lists are and express their 
definitions in terms of code. 


What is a list? 


Analogous to the notion of a shape, a list is an abstract notion. Recall how I 
built my list of groceries items? I started with a blank list: an empty list! 
The empty set! 


" An empty list is a list that has no element. " 


It is obvious that there are non-empty lists. But what do we mean by a non- 
empty list? How can we articulate such an obvious notion? Consider for 
example the following list consisting of three elements. 


e milk 
e bread 
e butter 


In the above, we organize the items in a linear fashion with milk being the 
first element, bread being the next element following milk and butter being 
the next element following bread. Is there any item that follows butter? 


Is 


e bread 
e butter 


a list? 
Is 
e butter 
a list? 
Is there a list that follows butter in the above? 


" A non-empty list is a list that has an element called first and a list 
called rest. " 


Note that in the above formulation, the rest of a list is itself a list! The 
definition of a list is an example of what we call a recursive definition: the 
list contains a substructure that is isomorphic to itself. 


List Design and the Composite Design Pattern 


The UML diagram below captures the recursive data definition of the list 
data structure. 
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This definition translates into Java code as follows. 


De: 

* Represents the abstract list structure. 
*/ 

public interface IList { 


} 
fA 
* Represents non- 
fr empty lists. 
* Represents empty */ 
lists. public class NEList 
we implements IList { 
public class MTList private Object 
implements IList { _first; 
} private IList 
_rest; 
} 


The above is an example of what is called the composite design pattern. 
The composite pattern is a structural pattern that prescribes how to build a 
container object that is composed of other objects whose structures are 
isomorphic to that of the container itself. In this pattern, the container is 
called a composite. In the above, [List is called the abstract component, 
MT List is called the basic component and NEList is called the composite. 
The composite design pattern embodies the concept of recursion, one of 
the most powerful thinking tool in computing. (There is a subject in 
theoretical computer science and mathematics called "recursive function 
theory," which studies the meaning of what computing means and in effect 
defines in the most abstract form what a computer is and what it can and 
cannot do.) 


List Creation 


Now that we have defined what a list is, we ask ourselves how we can 
process it? What can we do with a list? The above code makes it clear that 
there is not a whole lot we can do with a list besides instantiating a bunch of 
MT List objects via the call new MTList() (why?). Now that we are using 
the full Java language, we need to write a constructor for NEList in order to 
instantiate non-empty list objects with appropriate first and rest. The Java 
code for NEList now looks as follows (note how the comments are written). 


yess 

* Represents non-empty lists. 

up 

public class NEList implements IList { 
private Object _first; 
private IList _rest; 


Yee 

* Initializes this NEList to a given first 
and a given rest. 

* @param f the first element of this NEList. 

* @param r the rest of this NEList. 


i 

public NEList(Object f, IList r) { 
_first = f; 
_rest = 1; 

as 


The list structure as coded in the above is completely encapsulated, that is, 
all internal components (if any) of a list are private and cannot be accessed 
by any external code. Using the appropriate constructors, we can make a 
bunch of lists to store data but we cannot retrieve data nor do anything with 
these lists. In Object-Oriented Programming (OOP) parlance, the list is said 
to have no behavior at all. As such they are of no use to us. 


List Processing 


In order to perform any meaningful list processing at all, we need to 
program more "intelligence" into the list structure by adding appropriate 
methods to the list to provide the desired behaviors. So instead of asking 
what we can do with a list, the right question to ask in OOP is "what can a 
list do for us?" Let us start by presenting a few simple tasks that we want a 
list to perform and try to figure out how an "intelligent" list would carry out 
such tasks via some role acting. 


In class role-acting exercises: 


¢ Compute the length of a list. 
e Compute the sum of a list that holds integers. 


List Structure and the Interpreter Design Pattern 
Operations of the composite list structure are implemented using the 
Interpreter Design Pattern. 


List Processing 


In the previous lecture, we define what a list is and implement it using the 
composite design pattern. This list structure is fully encapsulated and does 
not expose any of its internal components. In order to manipulate such a list 
without having to make public its internals, we need to add methods to the 
structure. This lecture discusses the structure of the algorithms on the list. 


What can a list do? 


Length of a list 


Suppose we are given a list L and asked to find out how many elements it 
has. What should we do? The temptation here is to start thinking about 
"traversing" the list and keep a count as we go along, and when we 
encounter the "end" of the list, the count should be the number of elements 
in the list. But how do we know that that's the right answer? In order to 
determine whether or not the result obtained by counting as one traverses 
the list from beginning to end is correct, we have to define what it means to 
be the number of elements in the list. The number of elements in a list is an 
abstract notion, isn't it? In order to define such a quantity, we need to go 
back to the definition of what a list is. 


e A list is an abstract notion of a container structure. 

e An empty list is a list that has no element 

e A non-empty list is a list that has an element called first and a list 
called rest. 


To define the notion of the number of elements in a list, we need to define 
what we mean by the number of elements in an empty list and what we 


mean by the number of elements in a non-empty list. 


e The number of elements in a list is an abstract notion because the list is 
an abstract notion. 

e The number of elements of an empty list is 0. 

e The number of elements in a non-empty list that contains first and rest 
is 1 plus the number of elements in rest. 


The definition of the number of elements in a list is thus recursive. The 
recursive characteristic of this definition arises naturally from the recursive 
characteristic of the list structure. What ever approach we use to compute 
the number of elements in a list, in order to prove correctness, we must 
show that the result satisfies the above definition. 


Here is the code for the above computation. 


package listFw; 
P fas 
* Represents the abstract list structure. 
ag 
public interface IList { 
es 
* Abstract notion of the number of 
elements in this IList. 
ae 
public int getLength(); 


Top-level abstract list definition 


package listFw; 
j= 
* Represents empty 
lists. 
*7 
public class MTList 
implements IList { 
jr 
* The number of 
elements in an 
* empty list is 
zero. 
a 
public int 
getLength() { 
return 0; 
} 


package listFw; 
fee 
* Represents non-empty 
lists. 
Py, 
public class NEList 
implements IList { 
private Object 
first; 
private IList _rest; 
// Constructor 
ommitted. 


J** 
* The number of 
elements in a non-empty 
* list is the 
number of elements of 
its 
* rest plus 1. 
ae 
public int 
getLength() { 
return 1 + 
_rest.getLength(); 


i 


Concrete list implementations 


The above coding pattern is an example of what is called the interpreter 
design pattern: we are interpreting the abstract behavior of a class (or 
interface) in each of the concrete subclasses (or implementations). The 


composite pattern is a pattern to express the structure of a system, while the 
interpreter pattern is used to express the behaviors (i.e. methods) of the 
system. The interpreter pattern is usually applied to coding methods in a 
composite structure. In a later lecture, we shall see another way of 
expressing the behavior of a composite structure without having to add new 
methods and interpret them. 


Code Template 


Whenever we want the IList to perform a task, we add a method to IList and 
write appropriate concrete implementations in MTList and NEList. The 
following table illustrates the code template for writing the concrete code in 
MTList and NEList. 


interface IList 


public abstract returnType methodName(param 
List); 
// returnType may be ‘'void' 


NEList 
Object _first; 
IList _rest; 


MTList 
// no data 


public 
returnType 
methodName (param 
list) { 

f* 

This is in 
general the base 
case of a 
recursive call. 
Write the (non- 
recursive ) 

code to solve 
the problem. 

iw 

} 


In Class Exercises (Role-Acting) 


public returnType 
methodName(param list) { 

ie 

This is in general a 
recursive method. 

The code here can refer to 
_first and 

_rest, and all the methods 
in NEList 

When referencing _rest, one 
usually makes 

the recursive call: 
_rest.methodName(appropriate 
parameters). 

wes 

I 


Interpreter Pattern coding template for lists 


e Find a number in a list and return "Found it!" if the number is in the 
list otherwise return "Not found!" 

e Append a list B to a given list A and return a new list consisting of A 
and B concatenated together. 


Null Design Pattern 
Describe the Null Design Pattern: an object that does nothing. 


The Null Pattern is perhaps the most "intelligent" pattern of them all. It 
knows exactly what to do all the time, every time: nothing. Its usefulness is 
a little more subtle than that of other Design Patterns, but it can be used in 
many different situations. 


The Null Pattern is somewhat difficult to describe, since it resides in an 
abstract hierarchy tree, having no particular place at all, but occupying 
many roles. It is somewhat like the mathematical concept of zero: it is a 
placeholder, but is in itself nothing, and has no value. However, this means 
that Null is abstractly equivalent to any of the other concrete classes in the 
abstract hierarchy. Thus, it can be treated identically to any other class by 
the system. This gives consistent and predictable behavior for the null 
situation. Some objects’ behavior will depend upon its values, and since the 
Null Pattern has no values, it knows exactly what to do every time. It really 
does do nothing. And that's the most reliable code you'll ever see. 


One of the uses of the Null pattern is in the context of a Strategy Pattern. 
You have several behaviors that you want your host object to perform, but 
what if you want it to just do nothing? That's where you use a Null Pattern. 
The Null Pattern complies with the interface for a Strategy, but the bodies 
of its methods are blank, so it does nothing. 


Another popular use of the Null Pattern is in the context of a State Pattern. 
The easiest way to separate objects into two categories is along the 
difference between Null and Non-Null. Non-Null objects have values and 
do things, whereas Null ones do not. When working with a singly linked 
list, the Null node of the list is arguably the most important node in the list. 
It is the only node in the entire list that "knows what to do." When you 
perform a tail recursive operation on a singly linked list, each node asks the 
remaining portion of the list for more information in order to complete the 
assigned task. (remember: a singly linked list is defined in terms of nodes. 
Each node has a value (car) and a reference to the rest of the list. (cdr) The 
end of the list is reached when a node has no cdr.) It is only upon reaching 
the last node, the Null node, that any actual operations can be completed. 
The Null node will know exactly what to do: Nothing. Based upon this, the 


recursive calls made upon the elements of the list can be resolved, since 
there is a definite value to work with. 


Let's say that you have a list of objects that need to be drawn in a certain 
Container object (context). These objects are extensions of list nodes, and 
have only one extra method in them, which is the paint method. Each node's 
paint method consists of it asking its cdr to draw, and then actually drawing 
whatever it is that they draw onto the context. When you ask the first node 
to paint, it will ask the next node to paint, which will ask the next node to 
paint, and so on. How can we make this useful and not just a silly infinite 
delegation? The paint method of the last (and, supposedly, Null) node is 
empty. This means that it will do nothing, ant then return to the previous 
method that called it, so that all of the recursive calls down the list can 
resolve. This allows us to have an indefinite number of things to be painted 
in the list that can appear in any order. The only node in the list that matters 
is the last, Null node, which is the only one that actually knows what to do. 


State Design Pattern 

The State Design Pattern models objects that changes state, i.e. change 
behavior as a result of what has happened to them. This is also called 
"dynamic reclassification". 


Objects are often discussed in terms of having a "state" that describes their 
exact conditions in a given time, based upon the values of their properties. 
The particular values of the properties affect the object's behavior. For 
instance, one can say that the exact behavior of an object's getColor () 
method is different if the "color" property of the given object is set to "blue" 
instead of "red" because getColor() returns a different value in the two 
situations. 


Furthermore, the object may make decisions at run time as to exactly what 
to do dependent upon the values its properties possess. For instance, if the 
sky is blue (Sky. SetColor (Color .blue) ), then the sun should be 
visible. 


public boolean sunIsVisible() { 
if(getColor()==Color.blue) { return true; } else { 
return false; } } 


One issue with the above solution is that it is a hard-coded logic solution, 
not an architected solution. The sky does not intrinsically behave a certain 
way if it is blue, but rather it should figure out what to do in that situation. 


Wouldn't it be better if the sky intrinsically acted properly if it were blue? 
One could imagine two objects: a SkyBlue and a SkyNonBlue. The 
SkyBlue class' sunIsVisible( ) method would always return true 
while the SkyNonBlue version would always return false. 


What one needs now is the ability for a sky object to dynamically (i.e. at 
run time) change its class to/from SkyBlue and SkyNonBlue. What 
we'd like to accomplish is called "dynamic reclassification". 


We've seen code that does change its specific behavior depending on what 
particular strategy was installed. So, the setColor( ) method could 


install a strategy that would always return true if its sunIsSVisible( ) 


method were to be called. 
Exercise: 


Problem: But does the user of the Sky class care about the stratregy? 
Solution: 


Of course not. The user only cares that it does its job. 


The State Design Pattern is a fully encapsulated, self-modifying 
Strategy Design Pattern. 


+ Object : alMethod{Object aParam) 
void : setState(AState aState) 
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UML Class Diagram of the State Design Pattern 


One design pattern that is used very often in conjunction with the state 
pattern is the Null Object Pattern. 


Notice these things about the pattern: 


1. Any methods whose behaviors depend on the state of the object are 
simply delegated on in to the state, and handled there. Thus you will 
see the same methods in the context as in the states. Since the states 
are separate objects from the context, all the properties of the context 
need to have accessor methods that are at least package visible. 

2. The "Context" object needs to add a "set" accessor method so the 
states can modify which state is the active state. This method would be 
package visible so as to encapsulate the behavior away from the sight 
of the user. 


State Design Pattern 

Many real-life systems change the way they behave as they change states. It 
is desirable for object models of such systems to be able to change their 
behaviors as if they are changing types dynamically. The state design 
pattern is a design solution for this problem of dynamic reclassification. 
The key element is to abstract the state dependent behavior of the system in 
question as an abstract class and encapsulate each concrete variant behavior 
as a concrete subclass. 


When modeling real-life systems, we often find that certain objects in our 
system seem to change "state" during the course of a computation. 


Examples of changing state: 


1. A kitten grows up into a cat 

2. A car runs into a telephone pole and becomes a wreck. 

3. A friend is sad one day, happy another, and grumpy on yet another day. 
4. A list changes from empty to non-empty when an element is added. 

5. A fractal becomes more complex when it grows 

6:61; GIc. 


The cat and the kitten are the same animal, but they don't act identically. A 
car can be driven but a wreck cannot--yet they are the same entity 
fundamentally. Your friend is the same human being, no matter what their 
mood. Why shouldn't a list be the same list and a fractal be the same 
fractal? 


When something changes state, it is the same object, but yet it behaves 
differently. This phenomenon of having an objects change its behavior as if 
it were suddenly belonging to a whole different class of objects is called 
"dynamic reclassification". 


So far we've been using immutable data, and to create a non-empty list from 
an empty one, required that we make a whole brand-new list. With our use 
assignment ("=") previously, we've changed the value of a variable, but 
never the behavior the object it references. 


Consider this notion: We want to change the type of the object but we want 
to encapsulate that change so that the outside world does not see the type 
change, only the behavior change. 


Let's work with an example: 


Remember the old arcade game, "Frogger"? That's the one where a traffic- 
challenged amphibian attempts to hop across multiple lanes of speeding 
cars and trucks, hopefully without being converted into the road-kill-du- 
jour. 


(Here's an on-line version: http://www.gamesgnome.com/arcade/frogger/) 
Well, let's look at what a frog is here: 
A live frog 


e Has a well-defined position 

e Has a green color 

e Can move from place to place 
e Dies when hit by a vehicle. 


On the other hand, a dead frog 


e Has a well-defined position 

e Has a decided red color. 

e Cannot move from place to place 

e Doesn't die when hit by a vehicle because it is already dead. 


Using our trusty separation of variant and invariant, we can see that the 
position of a frog is an invariant but all the other behaviors are variants. 
Thus we want to separate out these variants into their own subclasses of an 
invariant abstract class. We then use composition to model the frog having 
an abstract state, which could be either alive or dead: 


Download the code here. 


<<IFrog=> 


+ Point : getPosd) 
+ Color : getColor() 


+ Point - moveBy(Point delta) 
+ Frog : getHit() 


. <<abstract state>> 


= Point - tng AFrogState 
ae AFrogSta = state Color : getColor(Frog context) 
= Point : moveBy(Frog context, Point delta) 


+ Point : getPos() 
+ Color : getColor() 
+ Point : moveBy(Point delta) 
+ [Frog : getHitQ) 
void : setState(AFrogState s) 


IFrog : getHit(Frog context) 


<<concrete state>> 
DeadState 


LiveState 
— LiveStateQ — DeadStateQ) 


Color : getColor(Frog context) Color : getColor(Frog host) 
Point : moveBy(Frog contest, Point delta) Point : moveBy(Frog host, Point delta) 


IFrog : getHit(Frog context) IFrog : getHit(Frog host) 


Click here to download the full javadoc documentation of the above code. 


The variant behaviors are represented by the abstract AFrogState, with 
the DeadState and LiveState implementing its abstract behaviors. 


(Note: The IFrog interface is there simply to allow different formulations 
of the frog to exist. See the Question below.) 


For those variant behaviors, all the main Frog does is to delegate (pass the 
call on to and return the result of) to the state that it has. If the state 
isa LiveState, then the Frog will act as if were alive because the 
LiveState only contains live-like behaviors. On the other hand, if the 
state is aDeadState, then the delegation to the state will produce 
dead-like behavior. The LiveState's getHit behavior will cause the 
Frog's_state to change from referencing a LlveState instance to 
referencing a DeadState instance. 


No conditionals are needed!! 


The Frog behaves the way it does because of what it is at that moment, 
not because of what it can figure out about itself then. 


This is an example of the State Design Pattern. Click here for more 
information on the State design pattern. 


From the outside, nothing about the internal implementation of Frog can 
be seen. All one can see is its public behavior. The implementations of the 
state design pattern are completely encapsulated (within the frog package, 
in this formulation).. For instance, if one is moving a live Frog, it will 
dutifully move as directed, but if in the middle somewhere, the Frog is hit, 
then it will immediately stop moving, no matter how much it is asked to do 
so. If one is checking its color, the live Frog is a healthy green but right 
after its accident, it will report that it is deathly red. 


Notice how the Frog changes its behavior and always behaves correctly for 
its situation, with no conditional statements whatsoever. 


Question: 


A very nice technique, when it is possible, is to implement the State pattern 
using anonymous inner classes. Can you write an IFrog implementation 
that encapsulates the states using nested class(es)and anonymous inner 
class(es)? 


e It can be done using only one publicly visible class and no package 
visible classes at all. 

e The only methods needed are those specified by IFrog. 

¢ How does using anonymous inner class(es) reduce the number of 
parameters passed to the state? 

e How does using the anonymous inner class(es) reduce the number of 
non-public methods? 


Onward! 


Looking way back to the beginning of the semester, we now have to ask, 
"Can we use this technology to create a mutable list? How will this affect 


the visitors and their execute function?" Hmmmm..... 


Union Design Pattern 


UML Diagram and Characteristics 


In general, the UML class diagram for the union design pattern looks like 
such: 
Union Design Pattern 


AbstractRepresentakon 


+ typel : operation] p 
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UML diagram of the union design pattern 


methods can be either Ds 
abstract or concrete. 


The characteristics of the union pattern are 


e 1 abstract superclass that represents the abstraction of all the 
subclasses. (Note that the superclass could be an interface.) The 
superclass can never instantiated because it does not represent any 
particular concrete entity. The methods of the superclass could be 
abstract (variant behaviors defined in the subclasses) or concrete (pure 
invariant behavior)--See below . 

e 2 or more subclasses (It is arguable whether or not a single subclass 
would qualify--if one considers that it might be possible that other 
subclasses could exist and are simply not coded yet, then one could 
argue that there is actually more than one subclass.) A subclass could 
be abstract, in which case, it would represent another abstraction layer. 


Corollary: Another way of thinking about the union pattern is to consider 
that the abstract superclass represents any of the subclasses. That is, 


anywhere the superclass is referenced, an instance of any of subclasses 
could be used. This is the essence of polymorphism. 


Examples 
Consider the following examples: 


1. Oranges, apples, pears, peaches, and mangos can all be abstractly 
represented as "fruit". Note that there is no such thing as a fruit that is 
not of some concrete sort, e.g. plum or strawberry. The concept of 
"fruit" is an abstraction that represents the union of oranges, apples, 
plums, etc. The notion of a fruit contains only the essence of what is 
common to all the concrete instances, such as containing seeds, having 
a sweet juicy flesh, etc. On the other hand, the notion of a fruit does 
not include specific information that pertains to only oranges--the 
number of orange sections it has, for instance--or to only strawberries - 
- the nature of its vine, for instance-- or to only any other particular 
kind of fruit. To talk about a fruit is to talk about all fruit at once -- 


the union of all types of fruit. 
Union of different fruits 


Fruit represents the union or abstraction of many types 
of specific things 


In the above UML class diagram, we see that oranges, apples, mangos 
and other concrete fruit classes all inherit from an abstract fruit class. 

2. Keyboards, mice, microphones, network ports and speakers are all 
input/output ("I/O") devices. An I/O device cannot exist without being 
a specific, concrete type of device, such as a keyboard or a speaker. 


Thus the concept of an "I/O device" is an abstraction of the union of 
all keyboards, printer ports, microphones, etc. The notion of an I/O 
device contains high-level issues about moving data into and out of a 
computer, but not any low-level concrete information about how it is 
done such as via a parallel or serial bit stream or how the data is 
formatted. "I/O device" refers to all possible types of input/output 
device. 

Union of different I/O devices 


OtherlODevices 


TODevice represents the union of many different types of 
specific devices 


As before, the UML class diagram shows us that the keyboard, mouse, 
network port and other concrete I/O devices inherit from an abstract 
I/O device class. 


Relationship to Abstraction and Variant/Invariant Principles 


Abstraction Layers 


One of the most important things that the union pattern does for an OO 
design is to define layers of abstraction. The abstract superclass represents 
a higher level of abstraction than the concrete subclasses. The union 
pattern thus defines two distinct abstraction levels. At any given moment, 
a program will that uses the classes involved in the union pattern will be 
running at either the lower, more concrete abstraction level or the higher, 
more abstract level. 


Good OO design pays careful attention to maintaining a consistent 
abstraction level in any given section of code. Changing abstraction levels 
in the middle of a process, particularly the decreasing of abstraction, 
effectively nullifies the power and flexibility of having made the abstraction 
in the first place. 


" WARNING! " "Simply having an abstract superclass does not 
automatically imply the existence of the union pattern! " 


Sometimes abstract superclasses are used to encapsulate and/or centralize 
shared or common code used in the subclasses. This gathering of code 
from the subclasses and relocating it to a superclass, often refered to as 
"hoisting", does not guarantee that the superclass is an abstraction of the 
subclasses. For instance, it would be convenient to put a field in "fruit" 
that tells us how many sections it has, because so many fruit, such as 
oranges, grapefruit, etc, form in sections. But the very fact that some fruit, 
such as mangos are not describable in terms of sections, means that to 
include such a field in "fruit" would compromise it as an abstraction of all 
fruit. When performing hoisting, one must be very careful to understand 
the difference between "universalizing"” (trying to do everything) and 
"abstracting" (capturing the essence of the problem). 


Variant vs. Invariant 


One of the most fundamental OO design decisions is where exactly to put 
the dividing line between the invariant, unchanging aspects of the problem 
and the variant, changing aspects. The union design pattern provides a 
clear representation of one type of variant-invariant separation. 


The abstract superclass is a representation of the essence that common to all 
possible concrete subclasses. It thus represents the invariant aspects of all 
elements in the union. 


The concrete subclasses, while all equivalent at a higher, more abstract 
level, are different from each other in some manner. They thus represent 
the variant aspects of the problem. 


Code that works at the abstraction level of the superclass is thus invariant 
code. It is capable of working with any instance of the concrete subclasses 
because it only deals with the invariant behavior of the superclass. The 
actual total behavior of the system is the invariant behavior of the abstract 
superclass plus the variant behaviors provided polymorphically by the 
instance of the concrete subclass being used. 


Glossary 


polymorphism 
The ability for a subclass instance to be used wherever its superclass 
(or implemented interface) is required. This is because all subclasses 
are abstractly equivalent to their superclasses. However, the use of 
different subclass instances in the same situation will produce differing 
resultant program behaviors because each subclass will behave in their 
own, differing concrete manners, even though those concrete behaviors 
are all abstractly equivalent. For more information, see the Wikipedia 
article on polymorphism and this web page on polymorphism and 
abstraction. 


hoisting 
The act of removing equivalent methods or fields common to all 
subclasses and moving them to their superclass. While this saves one 
from repeating code over and over again in the subclasses, the act of 
hoisting does not guarantee that the hoisted fields or methods are 
indeed true invariants of the subclasses. That is hoisting does not 
guarantee that the hoisted items are part of the abstraction of the 
subclasses. This is because hoisting assumes that all possible 
subclasses are known at the time the hoisting takes place, which is not 
always true. 


invariant 
Refers to anything that is the same across a set of classes. This 
includes attributes, concrete behaviors (methods) and abstract 
behaviors. The invariant properties constitute the abstraction of a set of 
classes. 


variant 
Refers to anything that is not the same across a set of classes. This 
includes attributes and concrete behaviors (methods). The variant 
properties create the unique definition of a class. 


Visitor Design Pattern 

Using the interpreter pattern to implement the overall behavior of a composite structure such as 
the list structure has one glaring drawback: it presents a static non-extensible interface to the 
client that cannot handle unforeseen future requirements. Each time a new behavior is needed 
to process the composite structure, new methods have to be added to the structure. As a result, 
the task of maintaining the code can quickly become unmanageable. The root of this problem 
comes from the lack of delineation between the intrinsic and primitive behaviors of the 
structure itself and its non-primitive application specific behaviors. The visitor design pattern 
offers a solution to this problem by decoupling these two kinds of behaviors into two separate 
systems of classes, hosts and visitors, that communicate with each other via only their public 
interfaces. Here the hosts are the composite structure with its invariant structural behaviors and 
the visitors are the infinitely varying algorithms that are to be performed on the structure. This 
approach turns a composite structure into a framework where control is inverted: one hands an 
algorithm to the structure to be executed instead of handing a structure to an algorithm to 
perform a computation. The structure is capable of carrying out any conforming algorithm, 
past, present, or future. Such a system of co-operating objects that is not only reusable and 
extensible, but also easy to understand and maintain. 


1. Decoupling Algorithms from Data Structures 


Recall the current formulation of the immutable list structure using the composite pattern. 


Represents IN 
imuautable lists. |- _ _ 


— Object : _first 
— IList : _ rest 


+ NEList(Object f, [List r} 


‘ 4 
1 4 


The unique aN Non-erapty list aN 
empty list. 


Each time we want to compute something new, we apply the interpreter pattern add appropriate 
methods to IList and implement those methods in MTList and NEList. This process of 
extending the capability of the list structure is error-prone at best and cannot be carried out if 
one does not own the source code for this structure. Any method added to the system can access 
the private fields of MTList and NEList and modify them at will. In particular, the code can 
change _ fist and _rest of NEList breaking the invariant immutable property the system is 
supposed to represent. The system so designed is inherently fragile, cumbersome, rigid, and 
limited. We end up with a forever changing [List that includes a multitude of unrelated 
methods. 


These design flaws come of the lack of delineation between the intrinsic and primitive behavior 
of the structure itself and the more complex behavior needed for a specific application. The 
failure to decouple primitive and non-primitive operations also causes reusability and 
extensibility problems. The weakness in bundling a data structure with a predefined set of 
operations is that it presents a static non-extensible interface to the client that cannot handle 
unforeseen future requirements. Reusability and extensibility are more than just aesthetic 
issues; in the real world, they are driven by powerful practical and economic considerations. 
Computer science students should be conditioned to design code with the knowledge that it will 
be modified many times. In particular is the need for the ability to add features after the 
software has been delivered. Therefore one must seek to decouple the data structures from the 
algorithms (or operations) that manipulate it. Before we present an object-oriented approach to 
address this issue, let's first eat! 


2. To Cook or Not To Cook 


Mary is a vegetarian. She only cooks and eats vegetarian food. John is carnivorous. He cooks 
and eats meat! If Mary wants to eat broccoli and cheese, she can learn how to cook broccoli 
and cheese. If she wants corn of the cob, she can learn how to cook com on the cob. The same 
goes for John. If he wants to eat greasy hamburger, he can learn how to cook greasy 
hamburger. If he wants to eat fatty hotdog, he can learn how to cook fatty hotdog. Every time 
John and Mary want to eat something new, they can learn how to cook it. This requires that 
John and Mary to each have a very big head in order to learn all the recipes. 


But wait, there are people out there called chefs! These are very special kinds of chefs catering 
only to vegetarians and carnivores. These chefs only know how to cook two dishes: one 
vegetarian dish and one meat dish. All John and Mary have to do is to know how to ask such a 
chef to cook their favorite dish. Mary will only order the vegetarian dish, while John will only 
order the meat dish! 


How do we model the vegetarian, the carnivore, the chef, the two kinds of dishes the chef 
cooks, and how the customer orders the appropriate kind of dish from the chef? 


The Food 


To simplify the problem, let's treat food as String. (In a more sophisticated setting, we may 
want to model food as some interface with veggie and meat as sub-interface.) 


The Food Consumers 


Vegetarians and carnivores are basically the same animals. They have the basic ingredients 
such as salt and pepper to cook food. They differ in the kind of raw materials they stock to 
cook their foods and in the way they order food from a chef. Vegetarians and Carnivores can 
provide the materials to cook but do not know how to cook! In order to get any cooked meal, 
they have to ask a chef to cook for them. We model them as two concrete subclasses of an 
abstract class called AEater. AEater has two concrete methods, getSalt and 
getPepper, and an abstract method called order, as shown in the table below. 


public abstract class AEater { 
public String getSalt() { 
return "salt"; 


} 
public String getPepper() { 
return "pepper"; 


} 
for 
* Orders n portions of appropriate food from restaurant 
ir 
oF 
public abstract String order(IChef r, Integer n); 
// NO CODE BODY! 
I 


Top-level abstract definition 


public class Vegetarian 


neh Tan ATAR Rn RAwnsann 


PUVLLG CladSS VLAIIILVUTS 
extends AEater{ 
public String getMeat() { 
return "steak"; 


extends AEater{ 
public String 
getBroccoli() { 
return "broccoli"; } 
J 
public String public String 


getCorn() sy getChicken( ) { 
return "corn": return "cornish hen"; 


} , 
public String public SE rang getDog( ) { 
order(IChef c, Object n) { Pectin portent 
// code to be mPa r 
discussed later; . ; 
: } va ad public String order (IChef 
} c, Object n) { 
; // code to be discussed 
later; 
} 
} 


Concrete implementations 


The Chef 


The chef is represented as an interface IChef with two methods, one to cook a vegetarian dish 
and one to cook a meat dish, as shown in the table below. 


interface IChef { 
String cookVeggie(Vegetarian h, Integer n); 
String cookMeat(Carnivore h, Integer n); 


Top-level abstract definition 


public class ChefWong 
implements IChef { 


public static final 
ChefWong Singleton 
= new Chefwong(); 
private ChefWong() {} 


public String 
cookVeggie( 
Vegetarian h, 
Integer n) { 


return n+" 
portion(s) of " + 


h.getCarrot() + ", " + 
h.getSalt(); 
is 


public String cookMeat ( 
Carnivore h, Integer 


n) { 


return n+" 
portion(s) of " + 
h.getMeat( ) 


h.getPepper(); 
} 
} 


Concrete implementations 


Ordering Food From The Chef 


To order food from an [Chef , a Vegetarian object simply calls cookVeggie, passing itself as one 


public class ChefZung 
implements IChef { 


public static final 
ChefZung Singleton 
= new ChefZung(); 
private ChefZung() {} 
public String 
cookVeggie( 
Vegetarian h, 
Integer n) { 
return n+" 
portion(s) of " + 
h.getCorn() 


h.getSalt(); 


public String cookMeat( 
Carnivore h, Integer 


n) { 


return n+" 
portion(s) of " + 


h.getChicken() + ", " + 
h.getPepper() + 


h.getSalt(); 


} 


of the parameters, while a Carnivore object would call cookMeat, passing itself as one of the 


parameters as well. The Vegetarian and Carnivore objects only deal with the IChef object at 
the highest level of abstraction and do not care what the concrete [Chef is. The polymorphism 
machinery guarantees that the correct method in the concrete [Chef will be called and the 
appropriate kind of food will be returned to the AEater caller The table below shows the code 
for Vegetarian and Carnivore, and sample client code using these classes. 


public class Vegetarian public class Carnivore 
extends AEater { extends AEater { 

// other methods elided // other methods elided 

public String public String 
order(IChef c, int n) { order(IChef c, int n) { 

return return 
c.cookVeggie(this, n); c.cookMeat(this, n); 
} 

} Mi 


Concrete implementations 


public void party(AEater e, IChef c, int n) { 
System.out.printin(e.order(c, n)); 
J 


// blah blah blah... 

AEater John = new Carnivore(); 
AEater Mary = new Vegetarian(); 
party(Mary, ChefWong.Singleton, 2); 
party(John, ChefZung.Singleton, 1); 


Client code 


The above design is an example of what is called the visitor pattern. 


e The abstract class AEater and its concrete subclasses are called the hosts. The method 
public String order(IChef c, Object n) is called the hook method. Each concrete subclasses 
of AEater knows exactly to call the appropriate method on the [Chef parameter, but does 
know and need not how the IChef concretely perforns its task. This allows an open-ended 
number of ways to cook the appropriate kinds of food. 

e The chef interface [Chef and all of its concrete implementations are called visitors. When 
an IChef performs cookMeat/cookVeggie, it knows that its host is a Carnivore/Vegetarian 
and can only call the methods of Carnivore/Vegetarian to cook a dish. Java static type 
checking will flag an error should there be a call on the host to getCarot in the method 
cookMeat. This is makes the interaction between hosts (Vegetarian and Carnivore) and 
visitors (IChef and all of its concrete implementations) much more robust. 


3. The Visitor Pattern 


The visitor pattern is a pattern for communication and collaboration between two union 
patterns: a "host" union and a "visitor" union. An abstract visitor is usually defined as an 
interface in Java. It has a separate method for each of the concrete variant of the host union. 
The abstract host has a method (called the "hook") to "accept" a visitor and leaves it up to each 
of its concrete variants to call the appropriate visitor method. This "decoupling" of the host's 
structural behaviors from the extrinsic algorithms on the host permits the addition of infinitely 
many external algorithms without changing any of the host union code. This extensibility only 
works if the taxonomy of the host union is stable and does not change. If we have to modify 
the host union, then we will have to modify ALL visitors as well! 


retum ¥-visitHostN (this, input); _. 
+ Object : accept(IVisitor v, Object input) 


return ¥-visitHost2 (this, input); BS 


+ Object : accept(I Visitor v, Object input} 
retum ¥-visitHostl (this, input); aS 
% 


+ Object : accept(IVisitor v, Object input} 


Calls on an [Visitor v to perform 
a task with a given input and 
retum some output Object. 


V 


+ Object : accepi{iVsitor v, Object put) 


calis on operates on | 


are 
epee ance . for + Object : visitHost] (AHost host, Object input) 


+ Object : visitHost2 (AHost host, Object input) 
+ Object : visitHostN(AHost host, Object input) 


+ Object : visitHost1(AHost host, Object input) 
+ Object : visitHost2(AHost host, Object input) 
+ Object : visitHostN(AHost host, Object input) 


+ Object : visitHost1(AHost host, Object input) 
+ Object : visitHost2(AHost host, Object input) 
+ Object : visitHostN(AHost host, Object input) 


Concrete implementations to NS 
perform concrete tasks. 


NOTE: All the "state-less" visitors, that is visitors that contain no non-static fields should be 
singletons. Visitors that contain non-static fields should not be singletons. 


4. Fundamental Object-Oriented Design Methodology (FOODM) 


1. Identify and separate the variant and the invariant behaviors. 


2. Encapsulate the invariant behaviors into a system of classes. 

3. Add "hooks" to this class to define communication protocols with other classes. 

4. Encapsulate the variant behaviors into a union of classes that comply with the above 
protocols. 


The result is a flexible system of co-operating objects that is not only reusable and extensible, 
but also easy to understand and maintain. 


Let us illustrate the above process by applying it to the design of the immutable list structure 
and its algorithms. 


1. Here, the invariant is the intrinsic and primitive behavior of the list structure, IList, and 
the variants are the multitude of extrinsic and non-primitive algorithms that manipulate it, 
IListAlgo. 

2. The recursive list structure is implemented using the composite design pattern and 
encapsulated with a minimal and complete set of primitive structural operations: 
getFirst() and getRest(). 

3. The hook method Object execute(IListAlgo ago, Object inp) defines 
the protocols for operating on the list structure. The hook works as if a [List announces 
to the outside world the following protocol: If you want me to execute your algorithm, 
encapsulate it into an object of type IListAlgo, hand it to me together with its inp object as 
parameters for my execute(). I will send your algorithm object the appropriate message 
for it to perform its task, and return you the result. 


o emptyCase(...) should be the part of the algorithm that deals with the case 
where I am empty. 

o nonEmptyCase(...) should be the part of the algorithm that deals with the case 
where I am not empty.” 


4. IListAlgo and all of its concrete implementations forms a union of algorithms classes 
that can be sent to the list structure for execution. 


Below is the UML class diagram of the resulting list design. Click here to see the full 
documentation. Click here to see the code. 


Represents algorithms aN veaiition: IN 
(Le. operations) on lists. ~--4% Object : emptpCase(MTList host, Objectinp) = 8 8 8 8 -----7- 
+ Object : nonEmptp Case (NEList host, Object inp) 


| | 
calls on| |operates on 


+ Object : execute (IListAigo algo, Object inp) 


Represents >» 
immutable lists. 


— Object : _first 


+ Object : execute(IListAlgo algo, Object inp) + NEList(Object f, [List r} 
4 + Object : getFirst(} 
7 1 + IList : getRest() 


4 
‘ + Object : execute(IListé. , Object in 
Team | DS . 1 (IListélgo algo, Object inp) 
empty list. x 
% - 


- s 
x - ‘ 


i x 


The above design is nothing but a special case of the Visitor Pattern. The interface IList is 


called the host and its method execute( ) is called a "hook" to the IListAlgovisitors. 
Via polymorphism, IList knows exactly what method to call on the specific IListAlgo 
visitor. This design turns the list structure into a (miniature) framework where control is 

inverted: one hands an algorithm to the structure to be executed instead of handing a structure 


to an algorithm to perform a computation. Since an IListAlgo only interacts with the list on 


which it operates via the list’s public interface, the list structure is capable of carrying out any 
conforming algorithm, past, present, or future. This is how reusability and extensibility is 
achieved. 


5. List Visitor Examples 


[** 
* Computes the length of the IList host. 
se 
public class GetLength implements IListAlgo { 
pee 
* Singleton Pattern. 
a 4 
public static final GetLength Singleton = new 
GetLength(); 
private GetLength() { } 


Singleton constructor for list algorithm 


[** 
* Return the length of the 
host's rest 


Fie * plus 1. 
* Returns Integer(0). * @param nu not used. 
* @param nu not used * @return Integer > 0. 
* @return Integer(0) ay 
ay public Object nonEmptyCase( 
public Object emptyCase( NEList host, Object... nu) 
MTList host, { 


Object... nu) { 
Object restLen 
return 0; = 
} host.getRest().execute(this); 
return 1 + 
(Integer )restLen); 


: 


Empty and non-empty cases of algorithm 


package listFw; 
fe 

* Computes a String reprsentation of IList showing a left 
parenthesis followed 

* by elements of the IList separated by commas, ending with 
with a right parenthesis. 

as 
public class ToStringAlgo implements IListAlgo { 

public static final ToStringAlgo Singleton = new 

ToStringAlgo(); 


private ToStringAlgo() { } 


Singleton constructor for list algorithm 


[** 

* Passes "(" + first to the 
rest of IList 

* and asks for help to complete 


the 
foo * computation. 
* Returns "()". oe 
af public Object nonEmptyCase( 
public Object emptyCase( NEList host, Object... inp) 
MTList host, { 
Object... inp) { 
return 
return "()"; host.getRest().execute( 


ToStringHelper.Singleton, 
"(" + host.getFirst()); 


} //closing parenthesis for the 
class 


Empty and non-empty cases of algorithm 


[** 


* Helps ToStringAlgo compute the String representation of 


the rest of the list. 
*/- 


class ToStringHelper implements IListAlgo { 
public static final ToStringHelper Singleton = new 


ToStringHelper(); 


private ToStringHelper() { 


Singleton constructor for helper visitor 


[EF 
* Returns the accumulated 
String + ")". 
* At end of list: done! 
a 
public Object emptyCase( 
MTList host, Object... 
acc) { 


return acc[O] + ")"; 


i 


/** 

* Continues accumulating the 
String 

* representation by 
appending ", " + first 

* to acc and recurse! 

*f 
public Object nonEmptyCase( 

NEList host, Object... 

acc) { 


return 
host.getRest().execute( 
this, 
acc[0] + ie Woy 
host.getFirst()); 


} 
} 


Empty and non-empty cases of algorithm 


We now can use to ToStringAlgo to implement the toString() method of an IList. 


package listFw; 


public class MTList 
implements IList { 


[** 
* Singleton Pattern 
“ef 
public final static 
MTList Singleton 
= new MTList(); 


private MTList() { 


[** 

* Calls the empty 
case of the 

* algorithm algo, 
passing to it 

* itself as the 
host parameter 

* and the given 
input inp as the 

* input parameter. 

* This method is 
marked as final 

* to prevent all 
subclasses from 

* overriding it. 
Finalizing a 

* method also 
allows the compiler 

* to generate more 
efficient 

* calling code. 


package listFw; 


public class NEList implements 


IList { 
[** 
* The first data element. 
*/ 
private Object _first; 
[te 


* The rest or "tail" of 
this NEList. 
* Data Invariant: _rest 
!= null; 
ey 
private IList _rest; 
[** 
* Tnitializes this NEList 
to a given 
* first and a given rest. 
* @param f This NEList's 
first element 
* @param r !=null; rest 
of this NEList. 


of 
public NEList(Object f, 
IList r) { 
Sars. S57 
_rest =r; 
} 
fe 


* Returns the first data 
element of 

* this NEList. 

* Marked final for the 
above reasons. 

ay 


ae 
public final 
Object execute( 
IListAlgo 
algo, 


J 


Object... inp) 


return 
algo.emptyCase( 
this, inp); 


public String 
toString() { 
return 
(String )ToStringAlgo 
.Singleton.emptyCase(this); 
} 


; 


Download the above code here. 


public final Object 
getFirst() { 
return _first; 
} 


fs 
* Returns the rest of 
this NEList which 
* is an IList. 
* Marked final for the 
above reasons. 
af 
public final IList 
getRest() { 
return _rest; 


z 
YR 
* Calls the nonEmptyCase 
method of the 
* IListAlgo parameter, 
passing itself 
* as the host parameter 
and the given 
* input as the input 
parameter. 
* Marked final for the 
above reasons. 


ae 
public final Object 
execute( 
IListAlgo algo, 
Object... inp) { 
return 


algo.nonEmptyCase(this, inp); 


public String toString() { 
return 
(String )ToStringAlgo 


.Singleton.nonEmptyCase(this); 
} 
t 


Design Patterns for Sorting 

In 1985, Susan Merritt proposed a new taxonomy for comparison-based sorting algorithms. 
At the heart of Merritt's thesis is the principle of divide and conquer. Merritt's thesis is 
potentially a very powerful method for studying and understanding sorting. However, the 
paper did not offer any concrete implementation of the proposed taxonomy. The following is 
our object-oriented formulation and implementation of Merritt's taxonomy. 


The following discussion is based on the the SIGCSE 2001 paper by Nguyen and Wong, 
"Design Patterns for Sorting" [footnote]. 

D. Nguyen and S. Wong, “Design Patterns for Sorting,” SIGCSE Bulletin 33:1, March 2001, 
263-267 


Merritt's Thesis 

In 1985, Susan Merritt proposed that all comparison-based sorting could be viewed as 
“Divide and Conquer” algorithms.[footnote] That is, sorting could be thought of as a process 
wherein one first "divides" the unsorted pile of whatever needs to sorted into smaller piles 
and then "conquers" them by sorting those smaller piles. Finally, one has to take the the 
smaller, now sorted piles and recombines them into a single, now-sorted pile. 

S. Merritt, "An Inverted Taxonomy of Sorting Algorithms," Comm. of the ACM, Jan. 1985, 
Volume 28, Number 1, pp. 96-99 


We thus end up with a recursive definition of sorting: 
e To sort a pile: 


o Split the pile into smaller piles 
o Sort the smaller piles 
o Join the sorted smaller piles into a single pile 


We can see Merritt's recursive notion of sorting as a split-sort-join process in a pictoral 
manner by considering the general sorting process as a "black box" process that takes an 
unsorted set and returns a sorted set. Merritt's thesis thus contends that this sorting process 
can be described as a splitting followed by a sorting of the smaller pieces followed by a 
joining of the sorted pieces. The smaller sorting process can thus be similarly described. The 
base case of this recursive process is when the set has been reduced to a single element, 
upon which the sorting process cannot be broken down any more as it is a trivial no-op. 
Animation of the Merritt Sorting Thesis (Click the "Reveal More" button) 


Sorting can be seen as a recursive process that splits the unsorted items into multiple 
unsorted sets, sorts them and then rejoins the now sorted sets. When a set is reduced to a 
single element (blank boxes above), sorting is a trivial no-op. 


Merritt's thesis is potentially a very powerful method for studying and understanding 
sorting. In addition, Merritt's abstract characterization of sorting exhibits much object- 
oriented (OO) flavor and can be described in terms of OO concepts. 


Capturing the Abstraction 

So, how do we capture the abstraction of sorting as described by Merritt? Fundamentally, we 
have to recognize that the above description of sorting contains two distinct parts: the 
invariant process of splitting into sub-piles, sorting the sub-piles and joining the sub-piles, 
and the variant processes of the actual splitting and joining algorithms used. 


Here, we will restrict ourselves to the process of sorting an array of objects, in-place -- that 
is, the original array is mutated from unsorted to sorted (as opposed to returning a new array 
of sorted values and leaving the original untouched). The Comparator object used to 
compare objects will be given to the sorter's constructor. 

Abstract Sorter Class 


Concrete 
“Template Method” 


# int: split(Object{] A, int lo, int hi); abstract, 


# void: join(Object{] A, int lo, int s, int hi); relegated to 
subclasses 


The invariant sorting process is represented as an abstract 
class 


Here, the invariant process is represented by the concrete Sort method, which performs the 
split-sort-sort-join process as described by Merritt. The variant processes are represented by 
the abstract Solit and j0in methods, whose exact behaviors are indeterminate at this 
time. 


Above the methods are defined as following: 


final void sort(Object [] A, int lo, int hi) -- sorts the given unsorted 
array of objects, A, defined from index 1o to index hi, inclusive. This method is 
implemented here and marked final to enforce its invariance with respect to the 
subclasses. It is this method that implements Merritt's split-sort-join process. 


abstract int split(Object [] A, int lo, int hi) -- splits the given 
unsorted array of objects, A, defined from index Lo to index hi, inclusive, into two adjacent 
sub-arrays. The returned index is the index of the first element of the upper sub-array. The 
implementation of this abstract method is in the sub-classes. 


abstract void join(Object [] A, int lo, int s, int h1) -- joins 
two sorted adjacent sub-arrays of objects in the array A, where the lower sub-array is from 
index Lo to index S, inclusive, and the upper sub-array is from index s to index hi, 
inclusive. The implementation of this abstract method is in the subclasses. 


Here's the full code for the abstract ASorter class, the abstract superclass for all concrete 
sorters and the implementation of Merritt's template for sorting: 
ASorter class 


package sorter; 
public abstract class ASorter 


protected AOrder aOrder; 

[** 
* The constructor for this class. 
* @param aOrder The abstract ordering strategy to be used by any subclass. 
*/ 

protected ASorter(AOrder aOrder) 


this.aOrder = aOrder; 
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/** 
* Sorts by doing a split-sort-sort-join. Splits the original array into 
two subarrays, 
* recursively sorts the split subarrays, then re-joins the sorted subarrays 
together. 
* This is the template method. It calls the abstract methods split and 
join to do 
* the work. All comparison-based sorting algorithms are concrete 
subclasses with 
* specific split and join methods. 
* @param A the array A[lo:hi] to be sorted. 
* @param lo the low index of A. 
* @param hi the high index of A. 
*/ 
public final void sort(Object[] A, int lo, int hi) 


if (lo < hi) 


int s = split (A, lo, hi); 
sort (A, lo, s-1); 

sort (A, s, hi); 

join (A, lo, s, hi); 


} 


fet 

* Splits A[lo:hi] into A[lo:s-1] and A[s:hi] where s is the returned value 
of this function. 

* @param A the array A[lo:hi] to be sorted. 

* @param lo the low index of A. 

* @param hi the high index of A. 

*/ 


protected abstract int split(Object[] A, int lo, int hi); 


[** 
* Joins sorted A[lo:s-1] and sorted A[s:hi] into A[lo:hi]. 
* @param A A[lo:s-1] and A[s:hi] are sorted. 
* @param lo the low index of A. 
* @param hi the high index of A. 
*/ 
protected abstract void join(Object[] A, int lo, int s, int hi); 


[Es 
* An accessor method for the abstract ordering strategy. 
* @param aOrder 
*/ 

public void setOrder(AOrder aOrder) 


this.aOrder = aOrder; 


5 


Note: AOrder is an abstract ordering operator whose concrete implementations define the 
binary ordering for the object being sorted. The examples below, only use the 
AOrder.1t(Object x, Object y) method, which returns true if x < y. The 
sorting framework could easily be modified to use java. util.Comparator instead 
with no loss of generality. 


Template Design Pattern 
The invariant sorting process as described by Merritt is an example of the Template Method 
Design Pattern. 

Template Method Design Pattern 


+ invariant(...); 
# variantt{...); 
# variant2(...); 


White-box Framework: 


# variant1(...); # variant1(...); 
# variant2(...); # variant2(...); 


The Template Method Design Pattern describes an 
invariant concrete process in terms of variant, abstract 


methods. 


Here, the invariant process is represented by a concrete method of an abstract superclass. 
This concrete method's implementation is in terms of abstract methods of the same class. 
These abstract methods represent the variant processes and are implemented in the sub- 
classes. This type of class organization where the variant processes are relegated to sub- 
classes is also known as a white box framework. 


Concrete Sorters 


In order to create a sorter that can actually perform a sorting operation, we need to subclass 
the above ASorter class and implement the abstract Split and join methods. It should 
be noted that in general, the solit and j0in methods form a matched pair. One can argue 
that it is possible to write a universal join methods (a merge operation) but it would be 
highly inefficent in most cases. 


Example: 

Selection Sort 

Tradionally, an in-place selection sort is performed by selecting the smallest (or largest) 
value in the array and placing it in the right-most location by either swapping it with the 
right-most element or by shifting all the in-between elements to the left. The selection and 
swapping/shifting process then repeated with the sub-array to the left of the newly placed 
element. This continues until only one element remains in the array. A selection sort is 
commonly used to do something like a sort group of people into ascending height. 

Below is an animation of a traditional selection sort algorithm: 

Traditional Selection Sort Algorithm 


The extrema values are removed from an ever-shrinking 

unordered set and placed into the resulting sorted array. 

Here, the smallest values are removed from the left and 
placed to the right in the array. 


In terms of the Merritt sorting paradigm, a selection sort can be broken down into a splitting 
process that is the same as the above selection process and a trivial join process. Looking at 
the above selection and swap/shift process, we see that it is describing a the splitting off of 
a single element, the smallest, from an array. The process repeats recursively until there is 
nothing more to split off. The sorting of a single element is a no-op, so after that the 
recursion rolls back out though the joining process. But the joining process is trivial, a no- 
op, because the elements are already in their corret positions. The beauty of Merritt's insight 
is the realize that by considering a no-op as an operational part of a process, all the different 
types of binary comparison-based sorting could be unified under a common framework. 
Below is an animation of a Merritt selection sort algorithm: 

Merritt Selection Sort Process 


The splitting process splits off one element at a time, the 
smallest element, from the left and placed to the right in 
the array. The join process is a no-op because the 
elements are already in their correct places. 


The code to implement a selection sorter is straightforward. One need only implement the 
split and join methods where the split method always returns the 10+1 index because 
the smallest value in the (sub-)array has been moved to the index 1o position. Because the 
bulk of the work is being done in the splitting method, selection sort is classified as an 
"hard split, easy join" sorting process. In the Java implementation of the SelectionSorter 
class below, the sp1it method splits off the extrema (minimum, here) value from the sub- 
array, while the j0in method is a no-op. 

SelectionSorter class 


package sorter; 


es 


* A concrete sorter that uses the Selection Sort technique. 
if 
public class SelectionSorter extends ASorter 


{ 


pte 
* The constructor for this class. 
* @param iCompareOp The comparison strategy to use in the sorting. 
aed 

public SelectionSorter(AOrder iCompareOp) 


super (iCompareOp) ; 


Via 
* Splits A[lo:hi] into A[lo:s-1] and A[s:hi] where s is the returned value 
of this function. 
* This method places the "smallest" value in the lo position and splits it 
off. 
* @param A the array A[lo:hi] to be sorted. 
* @param lo the low index of A. 
* @param hi the high index of A. 
* @return lo+1 always 
21, 
protected int split(Object[] A, int lo, int hi) 
{ 
int s = lo; 
int i = 1lo+41; 
// Invariant: A[s] <= A[lo:i-1]. 
// Scan A to find minimum: 
while (i <= hi) 


if (aOrder.1t(A[i], A[s])) 
S = if 
i++; // Invariant is maintained. 
} // On loop exit: i = hi + 1; also invariant still holds; 
// this makes A[s] the minimum of A[lo:hi]. 


// Swapping A[lo] with A[s]: 
Object temp = A[lo]; 

A[lo] = A[s]; 

A[s] = temp; 

return lo + 1; 


} 


Iptre 
* Joins sorted A[lo:s-1] and sorted A[s:hi] into A[lo:hi]. 
* This method does nothing. The sub-arrays are already in proper order. 
* @param A A[lo:s-1] and A[s:hi] are sorted. 
* @param lo the low index of A. 
* @param s 
* @param hi the high index of A. 
aA 
protected void join(Object[] A, int lo, int s, int hi) 
{ 
} 
be 


What's interesting to note here is what is missing from the above code. A tradional selection 
sort aalgorithm is implemented using a nested double loop, one to find the smallest value 
and one to repeatedly process the ever-shrinking unsorted sub-array. Notice that the above 
code only has a single loop, which coresponds to the inner loop of a traditional 
implementation. The outer loop is embodied in the recursive nature of the sort template 
method in the ASorter superclass. 

Notice also that the selection sorter implementation does not include any explicit 
connection between the split and join operations nor does it contain the actual sort 
method. These are all contained in the concrete Sort method of the superclass. We 
describe the SelectionSorter class as a component in a framework (technically a 
"white box" framework, as described above). Frameworks display inverted control where 
the components provide services to the framework. The framework itself runs the 
algorithms, here the high level, templated sorting process, and call upon the services 
provided by the components to fill in the necessary processing pieces, e.g. the split and join 
procedures. 


Example: 

Insertion Sort 

Tradionally, an in-place insertion sort is performed by starting from one end of the arry, say 
the left end, and performing an in-order insertion of an element into the sub-array to its left. 
The next element to the right is then chosen and the insertion process repeated. At each 
insertion, the sorted sub-array on the left grows until encompasses the entire array. An 
insertion sort is a very typical way in which people will order a set of playing cards in their 
hand. 

Below is an animation of a traditional insertion sort algorithm: 

Traditional Insertion Sort Algorithm 


Starting from the left, elements from the immediate right 
are inserted into a growing sub-array to the left. 


In the Merrit paradigm, the insertion sort first splits the array or sub-array into two pieces 
simply by separating the right-most element. Recursively, the splitting process proceeds to 
from the right to the left until a single element is left in the sub-array. Sorting a one element 
array is a no-op, so then the recursion unwinds with the join process. The join process 
combines each single split-off element with its sorted sub-array partner to its left by 
performing an in-order insertion. This proceeds as the recusion unwinds until the entire 
array is fully sorted. In contrast to the selection sort, the bulk of the work is being done in 
the join method, hence classifying insertion sort as an "easy split, hard join" sorting 
process. 

Below is an animation of a Merritt insertion sort algorithm: 

Merritt Insertion Sort Process 


The right-most elements are first split-off one by one, 
starting at the right and moving left. The split-off 
elements are then joined by performing an in-order 
insertion to the left, starting at the left. 


In the Java implementation of the selection sorter below, the split method simply splits 
off the right-most element of the sub-array. The ]0in method performs an in-order 
insertion of the single split-off element into the larger sub-array to its left. 
InsertionSorter class 


package sorter; 


Vi 

* A concrete sorter that uses the Insertion Sort technique. 
yf 

public class InsertionSorter extends ASorter 


{ 


[pte 
* The constructor for this class. 
* @param iCompareOp The comparison strategy to use in the sorting. 
ey 

public InsertionSorter(AOrder iCompareOp) 


super (iCompareOp) ; 


a 
Visas 
* Splits A[lo:hi] into A[lo:s-1] and A[s:hi] where s is the returned value 
of this function. 
* This simply splits off the element at index hi. 
* @param A the array A[lo:hi] to be sorted. 
* @param lo the low index of A. 
* @param hi the high index of A. 
* @return hi always. 
Uf 
protected int split(Object[] A, int lo, int hi) 


return (hi); 


} 
jf tres 
* Joins sorted A[lo:s-1] and sorted A[s:hi] into A[lo:hi]. (s = hi) 
* The method performs an in-order insertion of A[hi] into the A[lo, hi-1] 
* @param A A[lo:s-1] and A[s:hi] are sorted. 
* @param lo the low index of A. 
* @param s 
* @param hi the high index of A. 
ss 
protected void join(Object[] A, int lo, int s, int hi) 
{ 


int j = hi; // remember s == hi. 

Object key = A[hi]; 

// Invariant: A[lo:j-1] and A[j+i:hi] are sorted and key < all 
elements of A[j+1:hi]. 

// Shifts elements of A[lo:j-1] that are greater than key to the 
"right" to make room 


// for key. 
while (lo < j && aOrder.1t(key, A[j-1])) 
{ 
ALI = Alje2]); 
A[Jj-41] = key; 
jzaj-1; // invariant is maintained. 
} // On loop exit: j = lo or A[j-1] <= key. Also invariant is still 
true. 
// AL Key; 
} 
} 


Exercise: 


Problem: 


The authors were once challenged that the Merritt template-based sorting paradigm 
could not be used to describe the Shaker Sort process (a bidirectional Bubble or 
Selection sort). See for instance, http://en.wikipedia.org/wiki/Cocktail sort. However, it 
can be done is a very straightforward manner. There are a number of viable solutions. 
Hint: think about the State Design Pattern. 


Solution: 


The solution is left to the student but is available from the authors if proof of non- 
student status is provided. 


For more examples, please see download the demo code. Please note that the ShakerSort 
code is disabled due to its use as a student exercise. 


